SQL Injection
又被稱為駭客的填字遊戲。意思是指駭客在可以輸入資料的地方，用一些惡意字串來竄改 SQL 語法，來達成竊取資料等非法目的。
防範方式：Prepare Statement（ＭySQL 的內建機制）
$sql = "INSERT INTO sophiechang_users(nickname, username, password) VALUES(?, ?, ?)"; // 把參數改成問號
$stmt = $conn->prepare($sql);
$stmt->bind_param('sss', $nickname, $username, $password); // 替換成準備好的參數
$result = $stmt->execute(); // 執行 query 語法
CSRF (Cross Site Request Forgery)
CSRF 又被稱為跨站請求偽造，是一種在 Web 的攻擊方式。 CSRF 可以在不同的 domain 底下，卻能偽裝成「使用者本人身份發出的 request」。會有這樣新型的攻擊型態，是因為瀏覽器的機制，當發送 request 的時候，會把 cookie 的內容帶上。假設你點入駭客提供的 A 網站連結，其實背後是發到了 B 網站的 request，如果 B 網站你是在登入的狀態，這樣就可以造成像是使用者本人發出的 request ，即便當時你沒有親自造訪 B 網站。
防範方式（推薦）
加上圖形驗證碼、簡訊驗證碼
經常使用在有金流操作的網站，多了一道檢查就可以確保不會被 CSRF 攻擊。加上 CSRF token
產生：Server，儲存：Server在 form 裡面新增 hidden 的程式碼 （註一），裡面所填的值由 server 隨機產生，並存放在 server 的 session 中。當按下 submit 之後，server 比對表單中的
csrftoken與自己 session 裡存在資料庫的是不是一樣，就可以確定是不是由本人發出的 request。（註一）hidden 程式碼
<input type="hidden" name="csrftoken" value="fj1iro2jro12ijoi1"/>Double Submit Cookie
產生：Server，儲存：Client一樣在表單中放入 CSRF token，但這次參照值不是存放在 server 裡，而是存在 cookie 裡。這個方式是利用 cookie 要相符合的話。就要從相同的 domain 帶上來。攻擊者無法從不同 domain 帶上相同 cookie。
Client 端生成的 Double Submit Cookie
產生：Client，儲存：Client若是遇到是以 SPA 為主的專案，要從 sever 端拿到 CSRF token 會有點困難，所以改成從 clinet 生成。由 client 生成的 cookie 只要確保攻擊者無法取得、沒有包含任何敏感資訊的話，就不用擔心安全性考量。
防範方式（最推薦）
- 瀏覽器端的防禦： SameSite cookie
運作原理就是幫 Cookie 加上一層驗證，不允許跨站請求。意思是除了 A 網站這個 domain 發出的請求，其他 domain 發出的 request 不會帶上此 Cookie。而 SameSite 有兩 種模式， Lax 與 Strict，默認會是後者。
Set-Cookie: session_id=ewfewjf23o1; SameSite=Strict
Set-Cookie: foo=bar; SameSite=Lax
Strict 嚴格
<a href="">、<form>、new XMLHttpRequest... 等標籤，只要瀏覽器驗證不是在同一個 domain 發出的 request，就不會帶上 cookie。
Lax 寬鬆
上述的標籤可以帶上 cookie；使用 GET 形式也會帶上 cookie （無法防止 CSRF） ，但若是其他的 POST、DELETE、PUT...都不會帶上 cookie。
